Various organizations make use of enterprise resource planning (ERP) software architectures to provide an integrated, computer-based system for management of internal and external resources, such as for example tangible assets, financial resources, materials, customer relationships, and human resources. In general, an ERP software architecture is designed to facilitate the flow of information between business functions inside the boundaries of the organization and manage the connections to outside service providers, stakeholders, and the like. Such architectures often include one or more centralized databases accessible by a core software platform that consolidates business operations, including but not limited to those provided by third party vendors, into a uniform and organization-wide system environment. The core software platform can reside on a centralized server or alternatively be distributed across modular hardware and software units that provide “services” and communicate on a local area network or over a network, such as for example the Internet, a wide area network, a local area network, or the like.
As part of the installation process of the core software platform on computing hardware owned or operated by the organization, one or more customized features, configurations, business processes, or the like may be added to the default, preprogrammed features such that the core software platform is configured for maximum compatibility with the organization's business processes, data, and the like.
The core software platform of an ERP software architecture can be provided as a standalone, customized software installation that runs on one or more processors that are under the control of the organization. This arrangement can be very effective for a large-scale organization that has very sophisticated in-house information technology (IT) staff and for whom a sizable capital investment in computing hardware and consulting services required to customize a commercially available ERP solution to work with organization-specific business processes and functions is feasible. Smaller organizations can also benefit from use of ERP functionality. However, such an organization may lack the necessary hardware resources, IT support, and/or consulting budget necessary to make use of a standalone ERP software architecture product and can in some cases be more effectively served by a software as a service (SaaS) arrangement in which the ERP system architecture is hosted on computing hardware such as servers and data repositories that are maintained remotely from the organization's location and accessed by authorized users at the organization via a thin client, such as for example a web browser, over a network.
Many modern business software systems, including but not limited to ERP software system can be built upon metadata, which is generally defined as data that describes or otherwise provides information about other data. One type of metadata can include information regarding data elements of a data structure upon which a given data element has a dependency. The term data element, as used herein, can refer to any data format, including but not limited to a data object or business object, a node or a root node of a data or business object, and the like. The term dependency, as used herein, can refer to any unidirectional relationship between data elements, in which a dependent data element accesses data, metadata, data formats or structures, or the like from a depended upon data element.
As an example, a data element, such as a data object node, can be both a parent data object node and a child data object node in a web of inter-nodal dependencies and can depend on any number of child data object nodes and have any number of parent data object nodes that depend upon it. In a typical business software system, metadata can be distributed into meta-objects. A where-used list can be necessary to ensure metadata consistency and to make dependencies between meta-object instances transparent. As used herein, the term “where-used data” refers to an index, listing, or the like that contains information pertaining to associations or dependencies between data elements, for example data objects, nodes, or the like, of an object-based software solution.
A where-used listing can be necessary useful in resolving the typically one-way nature of inter-element dependencies. The data objects or data elements that depend upon data or data elements in a given data object are usually not known to or stored within that given data object. Currently available approaches to retaining a record of the web of inter-dependencies and associations that can arise in an complex object-based system is to hard-program an index of these dependencies, associations, or references. Such an approach can be effective in a static application environment or one that does not allow for customized features that are not included in an “off-the-shelf” version of the application. However, in a customizable software solution, the set of dependencies in each instance of the software solution can differ based on the specific business processes of an organization that the instance of the software solution is customized to support. Hard-programmed where-used listings are therefore not able to support the customizations of such a software solution.